NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/13435

Internet Message Format | 1996-08-05 | 5.3 KB

Path: news.sprintlink.net!datalytics!usenet
From: Rob Stewart <[e-mail]>
Newsgroups: comp.lang.c++
Subject: Re: Coding Standards
Date: Mon, 25 Mar 1996 14:09:31 -0500
Organization: Datalytics, Inc
Message-ID: <[e-mail]>
References: <4hj8ek$[e-mail]> <4hktar$[e-mail]> <4hmqol$[e-mail]> <4hsg8r$[e-mail]> <4i9o6j$[e-mail]> <4idskb$[e-mail]> <[e-mail]> <4io2i7$[e-mail]> <4isu2t$[e-mail]> <4j2jot$[e-mail]>
NNTP-Posting-Host: 204.62.224.71
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (WinNT; I)

Randy Charles Morin wrote:
>
> In article <4isu2t$[e-mail]>,
>    [e-mail] (John Marshall) wrote:
> >I think you have a hard time convincing anybody of this because it's
> >not true.  It seems to me that "data hiding" has to do with the actual
> >*text* of clients' source code, and that recompilation is merely an
> >implementation detail.
> >If we had really defeated the purpose of data hiding, the statement
> >would be: "if your data's type changes, then you have to rewrite all the
> >clients".  This is not the case when accessors are functions which just
> >happen to be inline.
> >Of course, in practice, all that recompilation during development is a
> >major pain.  I guess that's why people put what are going to be inline
> >accessors in library.inc, and include library.inc in either library.cpp
> >or (for inlining) library.hpp, dependant on whether it's a "dev make" or
> >"production make" respectively.  Certainly they're implementation -- they
> >don't *belong* directly in the header file.
> >Seems to me that the fundamental problem is that include files are
> >inherently broken compared to more automatic ways of managing the required
> >information.  Alas.
>
> Great, so your code is object oriented, encapsulated and has data hiding.  But
> your post compilation objects are not encapsulated and don't use data hiding.
>  That means, that if your object data member's changes types, then you have to
> make an effort to conform other objects to your changes.  If you don't have
> inline accessors, then you don't have a problem.  Is this so hard to
> understand?
>
> Imagine you are a producing a commercial system for several large
> corporations.  The large corporation use your hooks (sometimes inline
> accessors) to add functionality that is dependant on their particular business
> needs.  After shipping version 1.0 with an object of type char (inline
> accessed), you ship the less buggy version 1.1 with the data type changed to
> an int.  Now you have to coordinate your releases with the corporations.  If
> you eliminate inline accessors, then you don't have that problem.
>
> When you talk about having to rewrite code because you defeated data hiding,
> you are limiting your scope to the problems encountered by a small development
> environment.  This is not usually a problem when you are the only developer
> and you don't share code, but when you are sharing code with 100s of
> co-developers, you can't expect everybody to coordinate the changing of a data
> type.  I hope I've convinced another.
>

What you describe is fine if you want to ensure that a shared
library or DLL is a plug-in replacement for the previous
version.  However, if anything else changes, the users of
version 1.1 must rebuild anyway.  In that case, the change in
the type of the private dm accessed by an inline is just one
more change.  If you're building an application, your argument
has no bearing except to reduce compilation time (which is not a
vain effort, mind you).

The tradeoffs relate to performance and recompilation.  Sure, I
can build a compilation firewall that hides my entire
implementation in data pointed to by a single dm and accessed
through no inline functions.  That ensures that data
representation and manipulation are completely hidden within the
library and have no effect on the class user.

However, my experience reveals that changes as fundamental as
the type of dm usually result in the addition or subtraction of
one or more mfs, even if private.  Having done that, you've
triggered a recompilation for the class user.  In other words,
you're as likely to require a recompilation due to I/F changes
as for representation.

OK, you can extend the firewall such that the private mfs are
implemented in the representation class.  If you do that, you
will probably put all implementation in the representation
class.  That means all public and protected mfs of the public
class only forward to the corresponding representation class'
member functions.  That sounds like a recipe for efficient
software:  make all mfs non-inline function calls through a
pointer.  Let's make it worse:  for virtual functions we have a
non-line function call, through a pointer, to a function call
through a pointer.

I have exaggerated that slightly.  Some of the representation
class' mfs can be inlined, so some of the public class' mfs can
reduce to a few pointer dereferences.  That's still not great
for performance.

And you wonder why not everyone likes your approach.

--
Robert Stewart        | My opinions are usually my own.
Datalytics, Inc.    | [e-mail]